Vzor Saga: Implementace distribuovaných transakcí pro mikroslužby

Ve světě mikroslužeb může být udržování konzistence dat napříč několika službami významnou výzvou. Tradiční transakce ACID (Atomicita, Konzistence, Izolace, Trvanlivost), běžně používané v monolitických aplikacích, jsou často nevhodné pro distribuovaná prostředí. Zde přichází na řadu vzor Saga, který poskytuje robustní řešení pro správu distribuovaných transakcí a zajištění integrity dat napříč mikroslužbami.

Co je vzor Saga?

Vzor Saga je návrhový vzor používaný ke správě sekvence lokálních transakcí napříč několika mikroslužbami. Poskytuje způsob, jak dosáhnout eventuální konzistence, což znamená, že i když data mohou být dočasně nekonzistentní, nakonec se sblíží do konzistentního stavu. Místo spoléhání se na jedinou atomickou transakci, která se rozprostírá přes více služeb, vzor Saga rozděluje transakci na sérii menších, nezávislých transakcí, z nichž každou provádí jedna služba.

Každá lokální transakce v rámci Ságy aktualizuje databázi jedné mikroslužby. Pokud jedna z transakcí selže, Saga provede sérii kompenzačních transakcí, aby zvrátila změny provedené předchozími transakcemi, a tím efektivně vrátila celkovou operaci zpět.

Proč používat vzor Saga?

Několik faktorů činí vzor Saga cenným nástrojem pro správu transakcí v architekturách mikroslužeb:

• Volná vazba (Decoupling): Ságy podporují volnou vazbu mezi mikroslužbami, což jim umožňuje nezávisle se vyvíjet, aniž by ovlivňovaly ostatní služby. To je klíčová výhoda architektur mikroslužeb.
• Škálovatelnost: Tím, že se vyhýbají dlouhotrvajícím distribuovaným transakcím, Ságy zlepšují škálovatelnost a výkon. Každá mikroslužba může zpracovávat své vlastní transakce nezávisle, což snižuje soupeření o zdroje a zlepšuje propustnost.
• Odolnost: Ságy jsou navrženy tak, aby byly odolné vůči selháním. Pokud transakce selže, Sagu lze vrátit zpět, což zabraňuje nekonzistenci dat a zajišťuje, že systém zůstane v konzistentním stavu.
• Flexibilita: Vzor Saga poskytuje flexibilitu při správě složitých obchodních procesů, které se rozprostírají přes více služeb. Umožňuje definovat sekvenci transakcí a kompenzační akce, které mají být provedeny v případě selhání.

ACID vs. BASE

Pochopení rozdílu mezi ACID a BASE (Basically Available, Soft state, Eventually consistent) je klíčové při rozhodování, zda použít vzor Saga.

• ACID (Atomicita, Konzistence, Izolace, Trvanlivost): Zaručuje, že transakce jsou zpracovány spolehlivě. Atomicita zajišťuje, že buď všechny operace v rámci transakce uspějí, nebo žádná. Konzistence zajišťuje, že transakce převede databázi z jednoho platného stavu do druhého. Izolace zajišťuje, že souběžné transakce si navzájem nezasahují. Trvanlivost zajišťuje, že jakmile je transakce potvrzena, zůstane tak i v případě selhání systému.
• BASE (Basically Available, Soft state, Eventually consistent): Jedná se o odlišný přístup určený pro distribuované systémy. Basically Available znamená, že systém je většinu času dostupný. Soft state znamená, že stav systému se může v čase měnit, i bez vstupu. Eventually consistent znamená, že systém se nakonec stane konzistentním, jakmile přestane přijímat vstupy. Vzor Saga je v souladu s principy BASE.

Dvě hlavní strategie implementace vzoru Saga

Existují dva hlavní způsoby implementace vzoru Saga: Choreografie a Orchestrace.

1. Saga založená na choreografii

V Saze založené na choreografii se každá mikroslužba účastní Ságy tím, že naslouchá událostem publikovaným jinými mikroslužbami a podle toho reaguje. Neexistuje žádný centrální orchestrátor; každá služba zná své povinnosti a ví, kdy má provést své akce.

Jak to funguje:

1. Saga začíná, když mikroslužba publikuje událost oznamující začátek transakce.
2. Ostatní mikroslužby se přihlásí k odběru této události a po jejím obdržení provedou svou lokální transakci.
3. Po dokončení své transakce každá mikroslužba publikuje další událost oznamující úspěch nebo selhání své operace.
4. Ostatní mikroslužby naslouchají těmto událostem a podnikají příslušné kroky, buď pokračují k dalšímu kroku Ságy, nebo iniciují kompenzační transakce, pokud dojde k chybě.

Příklad: Zadání objednávky v e-shopu (Choreografie)

1. Služba pro objednávky (Order Service): Přijme nový požadavek na objednávku a publikuje událost `OrderCreated` (ObjednávkaVytvořena).
2. Služba pro skladové zásoby (Inventory Service): Odebírá událost `OrderCreated`. Po obdržení události zkontroluje skladové zásoby. Pokud jsou dostatečné, rezervuje položky a publikuje `InventoryReserved` (ZásobyRezervovány). Pokud jsou nedostatečné, publikuje `InventoryReservationFailed` (RezervaceZásobSelhala).
3. Služba pro platby (Payment Service): Odebírá událost `InventoryReserved`. Po obdržení události zpracuje platbu. Pokud je úspěšná, publikuje `PaymentProcessed` (PlatbaZpracována). Pokud selže, publikuje `PaymentFailed` (PlatbaSelhala).
4. Služba pro dopravu (Shipping Service): Odebírá událost `PaymentProcessed`. Po obdržení události připraví zásilku a publikuje `ShipmentPrepared` (ZásilkaPřipravena).
5. Služba pro objednávky: Odebírá událost `ShipmentPrepared`. Po obdržení události označí objednávku jako dokončenou.
6. Kompenzace: Pokud je publikována událost `PaymentFailed` nebo `InventoryReservationFailed`, ostatní služby naslouchají a provádějí kompenzační transakce (např. uvolnění rezervovaných zásob).

Výhody choreografie:

• Jednoduchost: Snadnější implementace pro jednoduché pracovní postupy.
• Decentralizace: Podporuje volnou vazbu a nezávislý vývoj mikroslužeb.

Nevýhody choreografie:

• Složitost: S rostoucím počtem účastníků Ságy se může stát obtížně spravovatelnou.
• Viditelnost: Obtížné sledování celkového průběhu a stavu Ságy.
• Vazba: I když podporuje volnou vazbu, služby si stále musí být vědomy událostí publikovaných jinými službami.

2. Saga založená na orchestraci

V Saze založené na orchestraci spravuje Sagu centrální orchestrátor (často implementovaný jako dedikovaná služba nebo stavový automat) a koordinuje provádění lokálních transakcí zúčastněnými mikroslužbami. Orchestrátor říká každé službě, co má dělat a kdy to má dělat.

Jak to funguje:

1. Saga začíná, když klient požádá orchestrátor o zahájení transakce.
2. Orchestrátor posílá příkazy zúčastněným mikroslužbám, aby provedly své lokální transakce.
3. Každá mikroslužba provede svou transakci a informuje orchestrátor o úspěchu nebo selhání.
4. Na základě výsledku orchestrátor rozhodne, zda pokračovat k dalšímu kroku, nebo zahájit kompenzační transakce.

Příklad: Zadání objednávky v e-shopu (Orchestrace)

1. Orchestrátor objednávek: Přijme nový požadavek na objednávku.
2. Orchestrátor objednávek: Pošle příkaz Službě pro skladové zásoby, aby rezervovala položky.
3. Služba pro skladové zásoby: Rezervuje položky a informuje Orchestrátor objednávek.
4. Orchestrátor objednávek: Pošle příkaz Službě pro platby, aby zpracovala platbu.
5. Služba pro platby: Zpracuje platbu a informuje Orchestrátor objednávek.
6. Orchestrátor objednávek: Pošle příkaz Službě pro dopravu, aby připravila zásilku.
7. Služba pro dopravu: Připraví zásilku a informuje Orchestrátor objednávek.
8. Orchestrátor objednávek: Označí objednávku jako dokončenou.
9. Kompenzace: Pokud některý krok selže, Orchestrátor objednávek pošle kompenzační příkazy příslušným službám (např. uvolnění rezervovaných zásob).

Výhody orchestrace:

• Centralizovaná kontrola: Snadnější správa a monitorování Ságy z centrálního bodu.
• Zlepšená viditelnost: Orchestrátor poskytuje jasný přehled o celkovém průběhu a stavu Ságy.
• Snížená vazba: Mikroslužby potřebují komunikovat pouze s orchestrátorem, což snižuje přímé závislosti mezi nimi.

Nevýhody orchestrace:

• Složitost: Zpočátku může být implementace složitější, zejména pro jednoduché pracovní postupy.
• Jediný bod selhání (Single Point of Failure): Orchestrátor se může stát jediným bodem selhání, ačkoli to lze zmírnit redundancí a opatřeními pro odolnost proti chybám.

Implementace kompenzačních transakcí

Klíčovým aspektem vzoru Saga je implementace kompenzačních transakcí. Tyto transakce se provádějí, aby zvrátily účinky dříve dokončených transakcí v případě selhání. Cílem je vrátit systém zpět do konzistentního stavu, i když celkovou Sagu nelze dokončit.

Klíčové aspekty pro kompenzační transakce:

• Idempotence: Kompenzační transakce by měly být idempotentní, což znamená, že mohou být provedeny vícekrát, aniž by se změnil výsledek. To je důležité, protože k selhání může dojít v kterémkoli bodě a kompenzační transakce může být opakována.
• Zpracování selhání: Kompenzační transakce mohou také selhat. Musíte mít strategii pro zpracování selhání v kompenzačních transakcích, jako je opakování, zaznamenávání chyb a upozorňování administrátorů.
• Konzistence dat: Kompenzační transakce by měly zajistit, že data zůstanou konzistentní. To může zahrnovat obnovení dat do jejich předchozího stavu, smazání nově vytvořených dat nebo aktualizaci dat tak, aby odrážela zrušení transakce.

Příklady kompenzačních transakcí:

• Služba pro skladové zásoby: Pokud Služba pro skladové zásoby rezervovala položky, ale platba selhala, kompenzační transakcí by bylo uvolnění rezervovaných položek.
• Služba pro platby: Pokud Služba pro platby zpracovala platbu, ale doprava selhala, kompenzační transakce by mohla zahrnovat vrácení peněz.

Výzvy a úvahy

I když vzor Saga nabízí významné výhody, přináší také některé výzvy a úvahy:

• Složitost: Implementace vzoru Saga může být složitá, zejména pro spletité obchodní procesy. Pečlivé plánování a návrh jsou nezbytné.
• Eventuální konzistence: Vzor Saga poskytuje eventuální konzistenci, což znamená, že data mohou být dočasně nekonzistentní. To může být problém pro aplikace, které vyžadují silné záruky konzistence.
• Testování: Testování Ság může být náročné kvůli jejich distribuované povaze a potenciálu selhání v různých bodech.
• Monitorování: Monitorování průběhu a stavu Ság je klíčové pro identifikaci a řešení problémů. Musíte mít zavedeny vhodné monitorovací nástroje a procesy.
• Idempotence: Zajištění, že transakce a kompenzační transakce jsou idempotentní, je klíčové pro zabránění nekonzistenci dat.
• Izolace: Jelikož Ságy zahrnují více lokálních transakcí, izolace může být problém. Mohou být vyžadovány strategie jako sémantické zámky nebo optimistické zamykání.

Případy použití a příklady

Vzor Saga je vhodný pro různé případy použití, zejména v distribuovaných systémech a architekturách mikroslužeb. Zde jsou některé běžné příklady:

• Správa objednávek v e-shopu: Jak je znázorněno v příkladech výše, vzor Saga lze použít ke správě celého životního cyklu objednávky, od vytvoření objednávky přes zpracování platby až po dopravu.
• Finanční transakce: Vzor Saga lze použít ke správě složitých finančních transakcí, které zahrnují více systémů, jako jsou převody finančních prostředků, žádosti o úvěr a pojistné události.
• Řízení dodavatelského řetězce: Vzor Saga lze použít ke koordinaci činností napříč několika subjekty v dodavatelském řetězci, jako jsou výrobci, distributoři a maloobchodníci.
• Zdravotnické systémy: Vzor Saga lze použít ke správě záznamů o pacientech a koordinaci péče napříč různými odděleními a poskytovateli.

Příklad: Globální bankovní transakce

Představte si scénář zahrnující globální bankovní transakci mezi dvěma různými bankami v různých zemích, které podléhají různým předpisům a kontrolám shody. Vzor Saga může zajistit, že transakce bude probíhat podle definovaných kroků:

1. Zahájení transakce: Zákazník zahájí převod prostředků ze svého účtu u Banky A (se sídlem v USA) na účet příjemce u Banky B (se sídlem v Německu).
2. Banka A - Validace účtu: Banka A ověří účet zákazníka, zkontroluje dostatek prostředků a zajistí, že na účtu nejsou žádná zadržení ani omezení.
3. Kontrola shody (Banka A): Banka A provede kontrolu shody, aby se ujistila, že transakce neporušuje předpisy proti praní špinavých peněz (AML) ani žádné mezinárodní sankce.
4. Převod prostředků (Banka A): Banka A odepíše prostředky z účtu zákazníka a pošle je do zúčtovacího centra nebo zprostředkovatelské banky.
5. Zpracování v zúčtovacím centru: Zúčtovací centrum zpracuje transakci, provede konverzi měny (USD na EUR) a přesměruje prostředky do Banky B.
6. Banka B - Validace účtu: Banka B ověří účet příjemce a zajistí, že je aktivní a oprávněný přijímat prostředky.
7. Kontrola shody (Banka B): Banka B provede vlastní kontrolu shody v souladu s německými a evropskými předpisy.
8. Připsání na účet (Banka B): Banka B připíše prostředky na účet příjemce.
9. Potvrzení: Banka B pošle potvrzovací zprávu Bance A, která poté informuje zákazníka, že transakce je dokončena.

Kompenzační transakce:

• Pokud kontrola shody v Bance A selže, transakce je zrušena a prostředky nejsou z účtu zákazníka odepsány.
• Pokud kontrola shody v Bance B selže, prostředky jsou vráceny Bance A a připsány zpět na účet zákazníka.
• Pokud dojde k problémům s konverzí měny nebo směrováním v zúčtovacím centru, transakce je zrušena a prostředky jsou vráceny Bance A.

Nástroje a technologie

Při implementaci vzoru Saga může pomoci několik nástrojů a technologií:

• Fronty zpráv: Apache Kafka, RabbitMQ a Amazon SQS lze použít k publikování a odebírání událostí v Saze založené na choreografii.
• Workflow enginy: Camunda, Zeebe a Apache Airflow lze použít k implementaci orchestrátorů a správě složitých pracovních postupů.
• Event Sourcing: Event sourcing lze použít ke sledování historie událostí v Saze a usnadnění vrácení zpět v případě selhání.
• Správci distribuovaných transakcí: Některé správce distribuovaných transakcí, jako je Atomikos, lze použít ke koordinaci transakcí napříč několika službami. Mohou však být nevhodné pro všechny architektury mikroslužeb kvůli svým inherentním omezením v distribuovaných prostředích.
• Saga frameworky: Existují také frameworky pro Ságy, které poskytují abstrakce a nástroje pro implementaci vzoru Saga.

Osvědčené postupy pro implementaci vzoru Saga

Pro efektivní implementaci vzoru Saga zvažte následující osvědčené postupy:

• Pečlivý návrh: Důkladně analyzujte své obchodní požadavky a navrhněte Sagu odpovídajícím způsobem. Identifikujte zúčastněné mikroslužby, sekvenci transakcí a kompenzační akce.
• Idempotence: Zajistěte, aby všechny transakce a kompenzační transakce byly idempotentní.
• Zpracování chyb: Implementujte robustní mechanismy pro zpracování chyb, abyste se vypořádali se selháními v kterémkoli bodě Ságy.
• Monitorování a logování: Implementujte komplexní monitorování a logování pro sledování průběhu a stavu Ság.
• Testování: Důkladně testujte své Ságy, abyste zajistili, že fungují správně a elegantně zvládají selhání.
• Sémantické zámky: Implementujte sémantické zámky, abyste zabránili souběžným aktualizacím stejných dat různými Ságami.
• Optimistické zamykání: Použijte optimistické zamykání k detekci a prevenci konfliktů mezi souběžnými transakcemi.
• Zvolte správnou implementační strategii: Pečlivě zvažte kompromisy mezi choreografií a orchestrací a zvolte strategii, která nejlépe vyhovuje vašim potřebám.
• Definujte jasné politiky kompenzace: Stanovte jasné politiky pro zvládání kompenzací, včetně podmínek, za kterých je kompenzace spuštěna, a konkrétních akcí, které mají být provedeny.

Závěr

Vzor Saga je mocným nástrojem pro správu distribuovaných transakcí v architekturách mikroslužeb. Rozdělením transakcí na sérii menších, nezávislých transakcí a poskytnutím mechanismu pro kompenzaci selhání vám vzor Saga umožňuje udržovat konzistenci dat a budovat odolné, škálovatelné a volně vázané systémy. I když může být implementace vzoru Saga složitá, výhody, které nabízí z hlediska flexibility, škálovatelnosti a odolnosti, z něj činí cenný přínos pro jakoukoli architekturu mikroslužeb.

Pochopení nuancí vzoru Saga, kompromisů mezi choreografií a orchestrací a důležitosti kompenzačních transakcí vám umožní navrhovat a implementovat robustní distribuované systémy, které splňují požadavky dnešních složitých obchodních prostředí. Přijetí vzoru Saga je krokem k budování skutečně odolných a škálovatelných architektur mikroslužeb, schopných s jistotou zvládnout i ty nejsložitější distribuované transakce. Nezapomeňte při aplikaci tohoto vzoru zvážit své specifické potřeby a kontext a neustále zdokonalovat svou implementaci na základě zkušeností z reálného světa a zpětné vazby.